Carrier Ethernet is evolving to support the needs of the carrier network environment. Carrier Ethernet requires scalable, reliable, and dynamic mechanisms to support operations, administration, and management (OAM) and traffic engineering (TE). Standards have been developed in the Metro Ethernet Forum (MEF), International Telecommunication Union (ITU), Institute of Electrical and Electronics Engineers (IEEE), and the like providing many of these required extensions. Specifically, Connectivity Fault Management (CFM) is an Ethernet standard to provide many common OAM functions associated with underlying network transport for services. For example, CFM is defined in IEEE 802.1ag-2007 IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management, the contents of which are herein incorporated by reference. Also, OAM functions are also defined in ITU-T G.8013/Y.1731 (July 2011) “OAM functions and mechanisms for Ethernet based networks,” the contents of which are herein incorporated by reference. Further, the MEF also defines Ethernet OAM in various technical specifications, such as MEF 17 (April 2007) “Service OAM Requirements & Framework,” the contents of which are herein incorporated by reference. Of course, other standards, specifications, and recommendations exist, are continually being added and updated, and are contemplated herein.
From an implementation perspective, Ethernet switches, nodes, devices, etc. require support for the various OAM protocols, and, conventionally, such support is a software-based feature. Software-based features and support have advantages of flexibility, i.e. protocol support can be easily updated, changed, added, etc., but disadvantages of processing efficiency and speed. As such, development has proceeded with hardware-based fault management support to delegate generation and processing of OAM protocol messages to hardware devices such as, without limitation, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Network Processors (NPs), and the like. Speed and efficiency are critical for carrier-grade environments. Hardware-based designs provide processing efficiency and speed but at the expense of flexibility. Specifically, a challenge in hardware-based fault management is that deep packet inspection for handling variable packet formats and TLV objects is expensive and difficult to implement.
Additionally, another challenge associated with hardware-based fault management includes handling fault detection on Link Aggregation Group (LAG) ports spread across multiple devices. LAG generally refers to systems and methods for combining, i.e. aggregating, multiple network connections in parallel to increase throughput beyond that of a single connection. Conventional systems and methods handle LAG ports via an OAM protocol manager in software. Disadvantageously, this approach is inefficient when a receive port of the LAG changes, the OAM protocol manager may generate false Loss of Continuity (LOC) alarms and disrupt the service. Problematically, OAM cannot be configured in hardware-based designs on LAG ports spread across multiple devices since each device is monitoring Continuity Check Messages (CCMs) separately.